1. Field of the Invention
The present invention relates to an optimized variable allocation method, optimized variable allocation system, and computer-readable memory containing an optimized variable allocation program, and more particularly to an optimized variable allocation technology which allocates variables efficiently to reduce an object code size of a target program and to increase program execution speed.
2. Description of the Related Art
A program for use on a computer system is developed in the following sequence: a developer creates a source program in a programming language such as C or Fortran, and then the created source program is translated into machine language. In creating a source program, the developer codes, in most cases, statements that perform calculation using variables. These variables are defined to temporarily contain intermediate calculation results.
FIG. 1 is a diagram showing a conventional variable allocation specification method. Where to allocate a variable is explicitly specified by a qualifier at variable declaration time. In FIG. 1, .sub.-- tiny specifies an 8-bit address area, .sub.-- near specifies a 16-bit address area, and .sub.-- far specifies a 24-bit address area. Unless explicitly specified, a variable is usually allocated in the largest area, .sub.-- far.
FIG. 2 is a diagram showing an example of memory address mapping of .sub.-- tiny, .sub.-- near, and .sub.-- far variables. The .sub.-- tiny, which indicates the 8-bit address area as described above, ranges from (0x00) to (0xff). The address of a location in this area may be represented by one byte. The .sub.-- near, which indicates the 16-bit address area, ranges from (0x100) to (0xffff). The address of a location in this area may be represented by two bytes. The .sub.-- far, which indicates the 24-bit address area, ranges from (0x10000) to (0xffffff). The address of a location in this area may be represented by three bytes.
As you see in the above description, the address of a variable allocated in a low-order address area, such as the .sub.-- tiny area, may be represented by a smaller number of bits. When translated into object code, a variable allocated in this area requires less space. Therefore, specifying a low-order area for a variable reduces the object code size.
The .sub.-- tiny area, which requires the smallest number of bits to represent an address, is smallest, it may contain a limited number of variables in many cases. Thus, a programmer has selected frequently-accessed variables and explicitly allocated them in the .sub.-- tiny area and .sub.-- near area. The programmer has allocated variables in those areas because of the following two reasons: to reduce the object code size of a statement which accesses the variables allocated in those areas and to speed up the program.
Allocation of frequently-accessed variables in an area, such as .sub.-- tiny area and .sub.-- near area where an address may be represented by a smaller number of bits, reduces the object code size of a statement which will access the variables in those areas, thus speeding up the program.
Conventionally, a programmer has explicitly specified where to allocate variables. Actually, however, a program is optimized while it is compiled by a special language translation system and translated into an executable module. This means that, in some cases, some variables are accessed less frequently than anticipated. In addition, as a program becomes larger, it is more difficult to estimate the access frequency of variables precisely, making more difficult to reduce the object code size and to speed up the program.
For example, the source program shown in FIG. 3 contains functions and iteration statements. The number of iterations of the two iteration statements 25 and 26 contained in the function tuple(), indicated by numeral 23, is not predictable on a source program level.
If the programmer knows that the iteration statement 26 is iterated frequently, he or she estimates that the variables `array1` and `array2` declared by the external variable declaration statements 22a and 22b in the iteration statement 26 will be accessed more frequently than the variable `attribute` declared by the external declaration statement 21.
FIG. 4 shows a program generated by a special intermediate code processing system which optimizes intermediate code generated by a special language translation system. As shown in FIG. 4, the start addresses of the external variables `array1` and `array2`, which were assumed to be accessed frequently, are loaded into the registers by the load instructions 31 and 32. In FIG. 3, the assignment statement 28 is executed by the instruction group 35 in FIG. 4. In this instruction group, actual assignment is executed through the use of registers. As a result, the external variables `array1` and `array2`, though assumed to be accessed frequently, are actually accessed only once. That is, the variable `attribute` declared by the external variable declaration statement 21 is accessed more frequently than the variables `array1` and `array2` declared by the external variable statements 22a and 22b.
FIG. 5 is an object code map generated by the above-described method in which the programmer allocates external variables. In this diagram, many bits are used for the addresses of 81 and 82 which are accessed frequently, because the programmer could not estimate that they would be accessed frequently. As a result, the object code size is large and the program is slow.
As described above, it is difficult for the programmer to estimate precisely how frequent an external variable will be accessed. Allocation of external variables by the programmer sometimes brings about a result that does not match what the programmer expected.